Cream of the Crop 3

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 3 / Cream of the Crop 3.iso / utility / sfs100.zip / SFS3.DOC < prev next >

Wrap

Text File | 1994-02-20 | 58KB | 1,263 lines

SFS Disk Volume Layout ---------------------- An SFS volume is broken up into two parts, the boot sector which is used to identify the volume and store assorted status information, and the encrypted volume itself. If a program tries to read the boot sector, the SFS driver will assemble a pseudo-boot sector in memory and return that instead. If a program tries to write to the boot sector, the SFS driver will skip the boot sector while still writing any other sectors which may be requested. All data on the boot sector, both plaintext and encrypted, is stored in big-endian format following the convention used by international cryptographic standards. Care should to taken to ensure that the proper endianness is maintained when reading and writing the boot sector on little-endian systems (the performance of the current implementation was tested against the RS6000 version to confirm that endianness conversion was being done correctly). In the following discussion a BYTE is an 8-bit quantity, a WORD is a big- endian 16-bit quantity, and a LONG is a big-endian 32-bit quantity. There are no alignment restrictions for the data as stored on disk. All data is close-packed with no need for byte-padding for word or longword boundaries. The SFS Volume Header Record The boot record is the first sector in a disk volume, and is usually used to load a bootstrap code block which loads more code which eventually loads DOS or an operating system. In the case of SFS there is no bootstrap code as SFS partitions are not bootable. Instead, the boot record contains a volume header record holding identification information which SFS uses when mounting the volume, and encryption information to allow SFS to decrypt the volume. The information is stored as a series of variable-length data packets with fields in big-endian order. Although it might be desirable to store the data as DER-encoded ASN.1 (ISO 8824, ISO 8825), the amount of code necessary to decode this information is considerable, leading to excessively complicated loaders for the encrypted volume. In particular, it would make the use of automatic volume mounts for the SFS device driver virtually impossible. The SFS volume header may contain multiple data packets, currently up to four types are implemented (there is an additional fifth pseudo-packet type which is a null data packet). One packet identifies the volume, one contains encryption information needed to en/decrypt the volume, and one contains filesystem-specific information needed to access the volume. These packets are mandatory. Finally, an optional packet may be used to hold information for volumes accessible by multiple users. Each packet consists of a packet type identifier followed by the length of the data in the packet, and then by the packet data itself. The volume header is laid out as follows: Offset Size Type Description 0 4 BYTE[ 4 ] 'SFS1' identification string 4 2 WORD Information packet 1 ID 6 2 WORD Information packet 1 data length 8 ?? ???? Information packet 1 data n 2 WORD Information packet 2 ID n+2 2 WORD Information packet 2 data length n+4 ?? ???? Information packet 2 data .......... m 2 WORD Information packet n ID m+2 2 WORD Information packet n data length m+4 ?? ???? Information packet n data It is recommended that the order of the information packets be as follows 1. Volume information 2. Encryption information 3. Filesystem information 4. Other information (such as multiuser access data) although this is not essential. However some volume automount software which must run with severely limited resources may run into problems if the order of the data packets is not as expected. The remainder of the sector is filled with zeroes. Currently defined packet types are: Name Value Information type SFS_PACKET_NONE 0 Null packet SFS_PACKET_VOLUMEINFO 1 Volume information SFS_PACKET_ENCRINFO 2 Encryption information SFS_PACKET_DISK_BPB 3 Filesystem information SFS_PACKET_MULTIUSER 4 Multiuser access information Packet 0 - Null Packet This packet contains no information and is never explicitly set in an SFS volume header. However since the remainder of the header after the actual data is padded out with zeroes, it can be viewed as containing a succession of null packets. Packet 1 - Volume Information Packet The volume information packet contains the volume name, the volume creation time, and the volume serial number. The packet layout is as follows: Offset Size Type Description 0 2 WORD Volume information packet ID = 1 2 2 WORD Volume information packet data length 4 2 WORD Volume name character set identifier 6 2 WORD Volume name length 8 ?? BYTE[] Volume name n 4 LONG Volume date, stored as seconds since 1970 GMT n+4 4 LONG Volume serial number The character set identifier is one of the following: Value Type 0 ISO 646 character set 1 ISO 8859-1 character set 2 ISO 8859-2 charcater set 3 ISO 8859-3 character set 4 ISO 8859-4 character set 5 ISO 8859-5 character set 6 ISO 8859-6 character set 7 ISO 8859-7 character set 8 ISO 8859-8 character set 9 ISO 8859-9 character set ?? Reserved for future use The volume name is stored as an octet string immediately following the character set and length values. The recommended maximum length for the volume name field is 100 octets, in order to allow room for the remainder of the volume header. The volume creation data is stored as a count of seconds since midnight on 1st January 1970. Times are stored relative to GMT, although some operating systems may have trouble with time zones. The volume serial number is used mainly for identification purposes and has no special characteristics, but should be unique across volumes. Packet 2 - Encryption Information Packet The encryption information packet contains the algorithm identifier of the encryption algorithm being used, the iteration count used when setting up the keying information, the initialisation vector (IV) for the disk key, the encrypted disk key for the volume, and a key check value which may be used to verify that the correct decryption key has been given. The packet layout is as follows: Offset Size Type Description 0 2 WORD Encryption packet ID = 2 2 2 WORD Encryption packet data length 4 2 WORD Encryption algorithm identifier 6 2 WORD Encryption key setup iteration count 8 ?? BYTE[] Disk key IV n 128 BYTE[] Encrypted disk key n+128 2 WORD Key check value The encryption algorithm identifier is one of the following: Value Type 0 MDC/SHS ?? Reserved for future use The MDC/SHS algorithm uses the Secure Hash Standard as the block transformation in the MDC encryption algorithm. The size of the disk key IV depends on the encryption algorithm, and is equal to the block size of the encryption algorithm being used. In the case of MDC/SHS this is 160 bits or 20 bytes. The encrypted disk key contains 128 bytes of cryptographically strong random information whose derivation is given in the section "Generating Random Numbers" above. This data may be utilized as required by the encryption algorithm used for the particular disk volume. In the case of MDC/SHS the first 160 bits are used as the master disk IV from which individual sector IV's are generated as described in the section "The Use of an Initialization Vector", the next 512 bits are used as the en/decryption key, and the remaining 352 bits are ignored. Other algorithms with larger or smaller key spaces may use this data differently. The key check value is provided to give some warning about an incorrect password, and should be derived from the encryption key in some nontrivial manner which makes using the key check in an attack no easier than a standard known plaintext attack. In the case of MDC/SHS it is the last two octets in the key data buffer after the key setup operation has been performed (this value is never used as part of the encryption key, and is the product of 200 iterations of MDC/SHS over the user key). Packet 3 - Filesystem Information Packet The filesystem information packet contains identification information for the filesystem contained on the encrypted volume followed by encrypted filesystem-specific information needed to handle the volume. This information is highly system-specific. The packet layout is as follows: Offset Size Type Description 0 2 WORD Filesystem information packet ID = 3 2 2 WORD Filesystem information packet data length 4 2 WORD Filesystem type identifier 6 ?? BYTE[] Encrypted filesystem information The filesystem type identifier is one of the following: Value Type 0 MSDOS FAT filesystem - BPB data ?? Reserved for future use The encrypted MSDOS BPB data record corresponds directly to a standard BIOS parameter block and is laid out as follows: Offset Size Type Description 0 2 WORD Sector size in bytes 2 1 BYTE Sectors per cluster 3 2 WORD Number of boot sectors 5 1 BYTE Number of FAT copies 6 2 WORD Number of entries in root directory 8 2 WORD 16-bit number of sectors on disk 10 1 BYTE Media descriptor byte 11 2 WORD Number of sectors per FAT 13 2 WORD Number of sectors per track 15 2 WORD Number of heads 17 4 LONG Number of hidden sectors 21 4 LONG 32-bit number of sectors on disk Packet 4 - Multiuser Access Information The multiuser access information packet contains an identification number for the multiuser access data file needed to access the volume. This value is checked against an equivalent one in the access data file to ensure that the data file corresponds to the volume in question. In addition the presence of this packet signals to the user software that the volume has multiuser access enabled. The packet layout is as follows: Offset Size Type Description 0 2 WORD Multiuser access information packet ID = 4 2 2 WORD Multiuser access information packet data length 4 4 LONG Multiuser access data file ID SFS Multiuser Access File Layout -------------------------------- [The following information is preliminary and is bound to change at a moments notice] Associated with each SFS volume which has multiuser access enabled are one or more database files containing information on each user who has access to that volume. This consists of identification information for each user (in the case of a named database), access control information, and keying information needed to access the actual volume. The file is laid out as a simple flat database, which is adequate for its intended use since a user record is only retrieved once per database access, and generally the databases will be quite small. On a system with proper access control this file will be read-only for everyone but the volume administrator, but unfortunately under some operating systems and also DOS there is little access control and anyone with access to a sector editor can change their access rights. However at this level they can also change the SFS volume header and the behaviour of mountsfs and the SFS driver, so little is gained by attempting to plug this hole. In any case, the basic access to the volume is cryptographically controlled, and bypassing this goes beyond simply editing a file. In the future it may worthwhile implementing more heavy-duty controls, such as using public-key signed access permission tokens from the volume administrator to grant access for networked use. All data in the multiuser access database is stored in big-endian format following the convention used by international cryptographic standards. Care should to taken to ensure that the proper endianness is maintained when reading and writing the boot sector on little-endian systems (the performance of the current implementation was tested against the RS6000 version to confirm that endianness conversion was being done correctly). In the following discussion a BYTE is an 8-bit quantity, a WORD is a big- endian 16-bit quantity, and a LONG is a big-endian 32-bit quantity. There are no alignment restrictions for the data as stored in the database. All data is close-packed with no need for byte-padding for word or longword boundaries. An access database is broken up into two sections, a header record containing details on the database as a whole, and one or more individual user records. Database Header The database header is laid out as follows: Offset Size Type Description 0 4 BYTE[4] 'SFS1' identification string 4 2 WORD Database type identifier 6 4 LONG Encrypted volume serial number 10 2 WORD Number of user records in database 12 2 WORD Database name character set identifier 14 2 WORD Database name length 16 ?? BYTE[] Database name The identification string and database type identifier serve to identify the general database format. The type identifier is one of the following: Value Type 0 Anonymous database containing date, access, keyinfo records 1 Named database containing user name, date, access, keyinfo records ?? Reserved for future use An anonymous database contains no identification for any of the user records. Each keyinfo record is decrypted in turn until a valid record is found, and this keying information is then used to access the encrypted volume. A named database contains an idetifier for each user record. Lookup of the database is performed directly by user name, and then access proceeds as for the anonymous database. The encrypted volume serial number is the serial number of the volume this database is used to access. [Problem: Should be able to set to zero to keep corresponding volume anonymous] [Problem: Can lead to trouble if chsfs is used to change volume serial number. Perhaps change chsfs to disallow serial number change without also changing database serial number] The database name is the collective name for the database and the users in it. Example database names might be "Ancient Illuminated Seers of Bavaria" or "Trilateral Commission". The name is optional, and may be omitted by specifying a name with a length of 0 characters. Database Records Each record in the database is laid out as follows: Offset Size Type Description 0 2 WORD Record type identifier 2 2 WORD User name character set identifier 4 2 WORD User name length 6 ?? BYTE[] User name n 4 LONG Access valid from date n+4 4 LONG Access valid to date n+8 4 LONG Access rights bitstring n+12 ?? BYTE[] Keying information The record type identifier is one of the following: Value Type 0 Anonymous record containing date, access, and keyinfo 1 Named record containing user name, date, access, and keyinfo ?? Reserved for future use The user name is the name of the user entitled to access the SFS volume the database corresponds to. Under multiuser operating systems this will simply correspond to the userID which the user is known to the operating system under. Otherwise, the userID can be the users name or some similar identifying method capable of distinguishing users. If the record type is an anonymous record, the user name fields will not be present. [Problem: One user with many accounts. Allow multiple userID's per record? This could encourage password sharing though] The access valid date pair contains the date after which access to the SFS volume is permitted, and the date at which access rights to the volume expire. These are stored in the Unix seconds-since-1970 format. The access rights bitstring contains the access rights the user has to the SFS volume. [Problem: How? Use RWXRWXRWX? Or ASN.1-type strings with complex FTAM-type rights? ACL's?] The keying information is [what? Same as single-user keying information] Interfacing with SFS -------------------- The SFS device driver has a sophisticated control interface which allows complete configurability through the standard DOS IOCTL read and write calls, which are used to transfer data to and from the control channel of a device. It is recommended that you consult a system programming guide or your compilers documentation for more information on making DOS IOCTL calls. Many compilers provide standard routines for making these calls. In the following discussion a BYTE is an 8-bit quantity, a WORD is a little- endian 16-bit quantity, and a LONG is a little-endian 32-bit quantity. Note that these values will need endianness conversion after being read from the SFS volume header. How SFS Identifies Drives For floppy disk drives, a value of 0 usually corresponds to drive A: and a value of 1 usually corresponds to drive B:. For fixed disk drives a value of 0 with the high bit set (giving an actual value of 0x80) usually corresponds to the first physical drive and a value of 1 with the high bit set (giving an actual value of 0x81) usually corresponds to the second physical drive. These values correspond to physical drives and not logical volumes. A single physical drive may contain a number of logical volumes. Since the SFS driver runs below the level at which most operating systems operate, it will ignore the DOS drive mappings (in fact DOS can't even see the encrypted disk volume) and access the drive directly. Thus if there are more than the DOS standard of two floppy drives and two physical hard drives connected to the system it should still be able to access the drives and present them to the operating system as normal disk volumes. If the physical drive contains more than one logical volume, the offset of the start of the logical volume from the start of the physical drive is specified as a sector count. If the physical drive contains only one logical volume, this value is set to zero. Finding the start of the logical volume will usually entail parsing the partition table of the physical drive. Floppy drives have only one logical volume which is equivalent in size to the physical drive, fixed disks have one or more logical volumes on each physical volume. These logical volumes can contain different filesystems and operating systems, and not all may be accessible or visible to DOS. For more information on disk organization, refer to a good technical reference which covers disk drives, and then spend several days figuring out all the DOS quirks never mentioned in any reference. In the following text the term `physical volume' is used to refer to the physical drive being accessed and the term `logical volume' is used to refer to the drive as DOS sees it. Reading from the SFS Driver: The SFS driver processes both control channel read and control channel write requests. Initially, the drive number of the logical volume being used by the SFS driver must be found. This can be done by checking each possible logical drive as follows: for( driveNumber = 0; driveNumber <= 'Z' - 'A'; driveNumber++ ) { /* Try and read data from the device's control channel */ data <- ioctlRead( driveNumber ); /* Check for the SFS identification string */ if( first 4 bytes of data = 'SFS1' ) exit loop; } If, at the end of the loop's execution, the driveNumber is greater than the total number of drives in the system, the SFS driver has not been found, probably because it isn't present in the system. Otherwise, driveNumber contains the drive number of the logical volume which the SFS driver is making available, and the data packet contains assorted status information about the SFS volume corresponding to the driverNumber. The data packet returned by the SFS driver is as follows: Offset Size Type Description 0 4 BYTE[ 4 ] 'SFS1' identification string 4 2 WORD SFS unit number, starting from 0 6 2 WORD Physical drive the SFS volume is mounted on 8 4 LONG Sector offset of logical volume from start of physical volume, or 0 if logical volume corres- ponds to physical volume 12 2 WORD 0 = no disk mounted, 1 = disk mounted 14 2 WORD 0 = disk is read/write, 1 = disk is read-only 16 2 WORD Quick-unmount hotkey value (high byte = shift value, low byte = optional keyboard scan code) 18 2 WORD Auto-unmount time. -1 = no unmount timer set, 0 = timer set but expired, any other value = total unmount time in minutes 20 2 WORD Auto-unmount timeout actual minutes remaining before the unmount takes place 22 2 WORD Internal driver check code. 0 = no error, 1 = driver consistency check failed, 2 = individual unit consistency check failed. The unit number is used by SFS to handle multiple encrypted drives. This value starts at zero for the first unit, and identifies the volume being accessed. If queried via an IOCTL call on the volume's removability, the SFS driver will always indicate that the media is removable, even if the volume is on a fixed disk. This is because some disk cacheing software won't invalidate a drive's data, even if the driver signals that the media has changed, unless the volume is marked as being removable. This status information can be returned to the user in the form of a status message or an information dialog if desired (the physical drive and offset information can be used to read the volume name, date, and serial number from the encrypted volume). Writing to the SFS Driver Once the driver has been found, several types of data packet can be sent to the driver to control its operation. Each control packet begins with a WORD containing the magic value 'C0' which the SFS driver checks to ensure the packet is meant for it, and a WORD identifying the data packet type. The data packet types are: Name Value Information type PACKET_SET_DISKINFO 0 Disk parameters PACKET_SET_KEYINFO 1 Keying information PACKET_SET_READONLY 2 Set disk read-only status PACKET_SET_DRIVENO 3 Physical drive number to mount PACKET_SET_MOUNTSTATUS 4 Set mount status PACKET_SET_UNMOUNT 5 Set/clear quick-unmount hotkey value PACKET_SET_TIMEOUT 6 Set/clear timed unmount value These packets are explained in more detail below. All other values are reserved for future use. Packet 0 - Disk Parameters: This packet type is used to convey to the SFS driver various pieces of information about the physical characteristics of the disk drive, including the sector size, number of heads, total number of sectors, and so on. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 0 4 2 WORD Sector size in bytes 6 1 BYTE Sectors per cluster 7 2 WORD Number of boot sectors 9 1 BYTE Number of FAT copies 10 2 WORD Number of entries in root dir 12 2 WORD Number of sectors on disk 14 1 BYTE Media descriptor byte 15 2 WORD Number of sectors per FAT 17 2 WORD Number of sectors per track 19 2 WORD Number of heads 21 4 LONG Number of hidden sectors 25 4 LONG Number of sectors per disk, 32-bit Sending this data packet to the driver automatically unmounts the encrypted volume. Packet 1 - Keying information This packet type sets up the encryption information in the driver. It contains the en/decryption key, and the master IV for the encrypted volume. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 1 4 20 BYTE[ 20 ] Master IV for encrypted volume 24 64 BYTE[ 64 ] MDC/SHS keying information Sending this data packet to the driver automatically unmounts the encrypted volume. Packet 2 - Set disk Read-only Status This packet type sets the read-only status of the disk. Sending a value of 0 makes the disk read-only. Sending a value of 1 makes the disk read/write. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 2 4 2 WORD Read-only status: 0 = read-only, 1 = read/write Sending this packet type has no effect on the mount status of the volume. Packet 3 - Physical Drive Number to Mount This packet type sets the physical drive number and the offset of the logical volume on the physical drive, which the driver will en/decrypt. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 3 4 2 WORD Physical drive number (see text above) 6 4 LONG Sector offset of logical volume from start of physical volume, or 0 if logical volume corres- ponds to physical volume Sending this data packet to the driver automatically unmounts the encrypted volume. Packet 4 - Set mount Status This packet type sets the mount status of the drive. A value of 0 unmounts the drive, a value of 1 mounts the drive. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 4 4 2 WORD Mount status (0 = unmount, 1 = mount) Unmounting the drive using this packet type also destroys the encryption information held by the driver and forces all data still held in cache and disk buffers to be flushed to disk. This is the only sure way to erase all the encryption information, as it wipes not only the actual keying information but also most of the data area used by the driver and any data in cache and disk buffers. Merely sending an empty keying information packet will not perform this task. Packet 5 - Set/clear Quick-Unmount Hotkey Value This packet is used to set the hotkey value which the SFS driver checks for to quickly unmount an SFS volume, or to clear the hotkey handling. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 5 4 2 WORD Hotkey value (see below) The hotkey which the driver checks for can be any combination of the alt key, control key, left shift, and right shift (referred to as the shift code), and an arbitrary keyboard scan code. The recommended default value is a combination of the left and right shift keys. This information is encoded in the hotkey WORD as follows: The high 8 bits contain the shift code. This contains a set of bitflags which specify the shift keys the driver checks for, possibly in addition to an optional character code. The values are: Shift key Value (binary) Value (hex) Alt 00001000 08 Control 00000100 04 Left Shift 00000010 02 Right Shift 00000001 01 The encoding for the shift code portion of the default left+right shift hotkey is therefore 00000011 binary or 03 hex. The low 8 bits contain an optional keyboard scan code which the driver will check for in addition to the shift code. This value is used in combination with the shift code to specify a key combination to the driver, so that for example Alt-Z would be used as the quick-unmount hotkey, although care should be taken to ensure that none of a large number of existing special key combinations is reused for this). If the low 8 bits contain zeroes, the driver does not check for a keyboard scan code in addition to a shift code. The encoding for the keyboard scan code portion of the default left+right shift hotkey is therefore 00000000 binary or 00 hex. The overall value is the combination of the shift code and keyboard scan code, or 0300 hex for the default hotkey. Specifying a value of 0 in this word will disable hotkey checking in the driver. The hotkey quick-unmount is handled by hooking the int 9h keyboard interrupt. The interrupt handler which performs this task is installed either when the driver is loaded (if there is a volume to be automounted or a hotkey code is specified), or when mountsfs is run (which transmits a quick-unmount control packet to the driver). The interrupt handler checks for the programmed hotkey and unmounts the volume if it is detected. Subsequent quick-unmount control packets can be sent to the driver to change the actual hotkey value. Sending a value of 0 will disable hotkey checking and deinstall the keyboard interrupt handler. Packet 6 - Set/clear Timed Unmount Value This packet is used to set the unmount time after which the SFS volume is unmounted if no accesses are made to it. The packet layout is as follows: Offset Size Type Description 0 2 WORD Magic value 'C0' 2 2 WORD Packet type 5 4 2 WORD Timeout value in minutes before unmount takes place Specifying a value of 0 as the timeout value will disable the timed unmount feature in the driver. The timed unmount is handled by hooking the int 1Ch timer interrupt. The interrupt handler which performs this task is installed either when the driver is loaded (if a timeout value is specified at this time), or when mountsfs is run and a timeout value is specified (which transmits a timed unmount control packet to the driver). The interrupt handler decrements the timer and unmounts the volume if it expires. The timer is reset every time a media check packet is received by the driver, which allows normal DOS accesses to be detected but doesn't cause false triggering due to device driver control functions. Subsequent timed unmount control packets can be sent to the driver to change the actual timeout value. Sending a value of 0 will disable the timer and deinstall the timer interrupt handler. Controlling the Driver The SFS driver is initialized by sending it a series of control packets giving the disk information, the keying information, the physical drive and logical volume offset to access, the read/write status, and finally the mount command. The sequence of operations for mounting a volume is as follows: driveNumber <- find SFS drive number as outlined above; ioctlWrite( driveNumber, PACKET_SET_DISKINFO, \ disk information - packet type 0 ); ioctlWrite( driveNumber, PACKET_SET_KEYINFO, \ keying information - packet type 1 ); ioctlWrite( driveNumber, PACKET_SET_READONLY, \ drive to mount and vol.offs - packet type 3 ); ioctlWrite( driveNumber, PACKET_SET_DRIVENO, \ read-only status - packet type 2 ); ioctlWrite( driveNumber, PACKET_SET_MOUNTSTATUS, \ mount status TRUE - packet type 4 ); To mount a new volume on the same drive: driveNumber <- find SFS drive number as outlined above; ioctlWrite( driveNumber, PACKET_SET_KEYINFO, \ keying information - packet type 1 ); ioctlWrite( driveNumber, PACKET_SET_MOUNTSTATUS, \ mount status TRUE - packet type 4 ); To unmount a volume, erasing the keying information held by the device driver: driveNumber <- find SFS drive number as outlined above; ioctlWrite( driverNumber, PACKET_SET_MOUNTSTATUS, \ mount status FALSE - packet type 4 ); Interfacing with mountsfs ------------------------- In order to facilitate the use of SFS with other software such as graphical front-ends, mountsfs can be run in batch mode in which it accepts abbreviated forms of the usual commands and outputs more complex results to fixed-record data files instead of the screen. Controlling mountsfs in Batch Mode In order to enable these features, the first option given to mountsfs must be the keyword `batch'. This allows it to recognise alternative single-letter forms of the normal commands. These single-letter options and their equivalent commands are as follows: Letter Full command f user file h hotkey i info or informaion n user name p password entry s status t timeout u unmount v volume name The volume name, hotkey, timeout, user name, and user file options must be followed by the appropriate extra information in the usual format. The password entry option should be followed by the password for the encrypted volume. For example to mount the volume "Test" with a quick-unmount hotkey of Ctrl-Alt-Z, an auto-unmount timeout of 10 minutes, and a password of "secret data" the command would be: mountsfs batch vTest hCtrlAltZ t10 "psecret data" which is equivalent to the usual: mountsfs vol=test hotkey=ctrlAltZ timeout=10 mountsfs Output in Batch Mode During normal operation mountsfs may print several lines of information to the screen giving details on the status of the operation being performed and details on currently mounted and unmounted SFS volumes. When mountsfs is run in batch mode, this information is written to a fixed-record data file named "sfs.tmp" instead of to the screen. The location of the file is given by the "TMP" environment variable; if this variable does not exist, the file is written to the root directory of the C: drive. If the TMP environment variable points to a drive without a path, the file is written to the root directory of that drive. Thus if the TMP environment variable were set as: set tmp=e:\data\ then mountsfs would output the results of the status or info/information command to the file "e:\data\sfs.tmp". If the variable were set as: set tmp=a: then mountsfs would output its data to the file "a:\sfs.tmp". The mountsfs output is written to the file as a series of fixed records. Each record is in ASCII text format with individual fields beginning on new lines, making parsing by external software a simple task. All control fields are in uppercase text. The exact record format is determined by the record type which is specified in the first line. In most cases the only record written will be the result from the mountsfs execution, although the status and info/information commands produce one or more extra output records which are detailed in the section "The status and info Commands in Batch Mode" below. The mountsfs result record is laid out as follows: Field Field contents Record type "RESULT" Success status "TRUE" or "FALSE" Error message <string : error message, or empty string> The record type field identifies the following record as being a mountsfs result record. The success status field gives the success status of the mountsfs command. A value of "TRUE" indicates the command succeeded, a value of "FALSE" indicates the command failed. The error message field gives the error message generated by mountsfs if the success status field is set to FALSE, or an empty string if the success status field is set to TRUE. A successful mountsfs command result record would be as follows: Field Field data Record type RESULT Success status TRUE Error message A failed mountsfs command result record might be as follows: Field Field data Record type RESULT Success status FALSE Error message Cannot find SFS driver The status and info Commands in Batch Mode Apart from the result record, mountsfs produces two other types of output records, the output from a status command and the output from an info/ information command. As with the RESULT record, each record is in ASCII text format with individual fields beginning on new lines, making parsing by external software a simple task. All control fields are in uppercase text. The exact record format is determined by the record type which is specified in the first line. This is either "STATUS" for the output from a status command, or "INFORMATION" for the output from an info/information command. The status command output record is laid out as follows: Field Field contents Record type "STATUS" Unit number <number : drive unit number> Mount status "TRUE" or "FALSE" Volume name <string : volume name, or empty string> R/W access allowed "TRUE" or "FALSE" Drive letter <character : uppercase driver letter> Hotkey <Ctrl, Alt, LeftShift, RightShift = 'c', 'a', 'l', 'r'> <Letter = uppercase letter. Example: Ctrl-Alt-Z = "caZ"> Timeout total time <number : time in minutes, or "FALSE"> Timeout time left <number : time in minutes, or "FALSE"> The record type field identifies the following record as being from the output of the status command. The unit number field is the drive unit number used by the SFS driver. The mount status field contains "TRUE" if there is a volume mounted, or "FALSE" if there are no volumes mounted. If this field contains the value "FALSE" then the following fields will contain null values (either the value "FALSE" or blank fields as appropriate). The volume name field contains the name of the volume. This may contain any type of character, or may be an empty string if no volume name is present. The R/W access allowed field contains "TRUE" if read/write access to the volume is allowed, or "FALSE" if write access is disabled and the volume is mounted read-only. The drive letter field contains the uppercase drive letter which the mounted SFS volume corresponds to. The hotkey field contains the quick-unmount hotkey value or "FALSE" if none is set. The shift keys (if any) are given in lowercase and the ASCII key value (if any) is given in uppercase. The shift key codes are Ctrl = 'c', Alt = 'a', leftShift = 'l', rightShift = 'r'. These are followed by the ASCII key value, if there is one. Thus the code for the default quick-unmount hotkey combination leftShift-rightShift would be "lr", and the code for the hotkey combaination Ctrl-Alt-Z would be "caZ". The timeout total time and timeout time left fields contain either the auto-unmount total time in minutes and the time left before the unmount takes place in minutes, or the control string "FALSE" if no timeout is set. A typical status command output record might be as follows: Field Field data Record type STATUS Unit number 0 Mount status TRUE Volume name Encrypted data R/W access allowed TRUE Drive letter G Hotkey lr Timeout total time 15 Timeout time left 4 This would then usually be followed by a RESULT record. The information command output record is laid out as follows: Field Field contents Record type "INFORMATION" Volume name charset <string : character set name, or "FALSE"> Volume name <string : volume name, or empty string> Volume date <string : date in YYMMDDHHMMSS format> Volume ID <number : volume serial number> Volume size <number : volume size in kilobytes, or "FALSE"> Filesystem type <string : filesystem type, or "FALSE"> Automount ID <string[8] : automount ID, or "FALSE"> Multiuser access "TRUE" or "FALSE" Mount status <character : uppercase driver letter, or "FALSE"> The record type field identifies the following record as being from the output of the info/information command. The volume name character set field contains the name of the character set used in the volume name. This is either "ISO 646", "ISO 8859-1", "ISO 8859-2", "ISO 8859-3", "ISO 8859-4", "ISO 8859-5", "ISO 8859-6", "ISO 8859-7", "ISO 8859-8", "ISO 8859-9", or "FALSE" if the character set is unknown. The volume name field contains the name of the volume. This may contain any character from the character set given in the Volume name character set field, or may be an empty string if no volume name is present. The volume date field contains the volume date in YYMMDDHHMMSS (two-digit year, month, day, hour, minute, second) format. The volume ID field contains the volume serial number. The volume size field contains the volume size in kilobytes, or "FALSE" if the volume is removable media. The filesystem type field contains the name of the filesystem the volume contains. This is either "DOS", or "FALSE" if the filesystem is unknown. The automount ID field contains the 8-character automount ID for the volume if the volume is on a fixed disk, or "FALSE" if the volume is on a removable disk and no automount is possible. The multiuser access field contains "TRUE" if multiuser access to the volume is possible or "FALSE" if only single-user access is possible. The mount status field contains the uppercase drive letter which the mounted SFS volume corresponds to if the volume is mounted, or "FALSE" if it is unmounted. The status command output records corresponding to the volumes given in the section "Mounting an SFS Volume" above would be as follows: Field Field data Record type INFORMATION Volume name charset ISO 646 Volume name Data backup Volume date 931101101301 Volume ID 1234 Volume size FALSE Filesystem type DOS Automount ID FALSE Multiuser access FALSE Mount status FALSE Record type INFORMATION Volume name charset ISO 646 Volume name Personal financial records Volume date 930906112219 Volume ID 177545 Volume size 10000 Filesystem type DOS Automount ID 03A12F7B Multiuser access FALSE Mount status E Record type INFORMATION Volume name charset ISO 646 Volume name Encrypted data disk Volume date 930412221700 Volume ID 69231461 Volume size 42456 Filesystem type DOS Automount ID 42DD2536 Multiuser access TRUE Mount status FALSE This would then usually be followed by a RESULT record. In order to make use of these records, the controlling program should invoke mountsfs in batch mode with either the `s' status or `i' information command. mountsfs will run and, if no errors are encountered, write its output to the output file. The controlling program can then read the data from the file, delete the file, and handle the information as appropriate. Selected Source Code -------------------- This section contains a walkthrough of selected portions of the source code (mainly the encryption-related parts) to allow the verification of its correctness and to help people wishing to write SFS-compatible software. [!!!! Not in the beta release to save space and because I haven't had time to add it yet, should be in a later final version !!!!] Future Work ----------- The following ideas may be incorporated into future versions of SFS if requested by users. In addition reasonable requests for other improvements may also find their way into SFS. - Improve error recovery for the encryption process. This is somewhat difficult, and will probably involve keeping a copy of status information and the track currently being encrypted on a local volume to allow a restart in the case of a power failure. There are problems inherent in this as it involves storing sensitive data in a disk file, and will slow down the processing considerably due to the need to write each track to two physically separate disk volumes instead of one continuous one. A partial solution is to keep the status information (simply an index of the disk section currently being encrypted) in the volume header while mksfs is running and provide some sort of restart option if power is lost, although what happens if power dies halfway through writing a track is uncertain. - A plug-in card which contains a BIOS extension which hooks int 13h and encrypts and entire physical disk (not just one disk volume), from the master boot record at the start to the very last sector at the end. This means all disk I/O must be done via int 13h and won't work on all systems. Cost for the card is estimated to be about $80-$100 for the basic version an up to $200 for the full hardware version whose throughput it significantly higher than the basic version. Recommended Reading ------------------- In recent years a large number of books and articles on crytography have appeared. Many of these are beyond the level of anyone with a casual interest in the subject, but a good overview is given by Dorothy Dennings (now somewhat dated) "Cryptography and Data Security", published by Addison-Wesley in 1982 (ISBN 0-201-10150-5). Bruce Schneier's much more recent "Applied Cryptography", published by John Wiley and Sons in 1993 (ISBN 0-471-59756-2), is probably the best single text on cryptography currently available, and is recommended reading for anyone wanting more information on the principles behind SFS. This book also contains a large list of references to more information on all manner of encryption algorithms, protocols, and technology. Voydock and Kent's tutorial "Security Mechanisms in High-Level Network Procotols", published in the ACM Computing Surveys Vol.15, No.2 (June 1983) provides a good overview of design considerations for encryption systems. The algorithms and techniques used in SFS are laid down in the following national and international standards: ANSI X3.106, "American National Standard for Information Systems - Data Encryption Algorithm - Modes of Operation" Australian Standard AS 2805.5.2, "Electronic Funds Transfer - Requirements for Interface", Part 5.2, "Ciphers - Modes of operation for an n-bit block cipher algorithm" ISO 10116:1991, "Information technology - Modes of operation for an n-bit block cipher algorithm" ISO 10126-2:1991, "Banking - Procedures for message encipherment (wholesale) - DEA Algorithm" NBS FIPS pub. 81, "DES Modes of Operation", 1980 NIST FIPS pub. 180, "Secure Hash Standard", 1993 Information on the weaknesses of some cryptosystems are published in a variety of places. The largest publicly available sources of information are the cryptography conference proceedings which are part of the Springer-Verlag "Lecture Notes in Computer Science" series. Eli Biham and Adi Shamir's "Differential Cryptanalysis of the Data Encryption Standard", also published by Springer-Verlag (ISBN 0-387-97930-1), gives information on the resistance to attack of a number of block ciphers. Finally, James Bamford's "The Puzzle Palace", published by Houghton-Mifflin in 1982, is a good source of information on the operation of the NSA, albeit slightly dated (it predates the widespread availability of encryption for personal computers, for example). This list only scratches the surface of the full range of cryptographic and security literature available - a very detailed bibliography can be found in the "Applied Cryptography" book. Using SFS --------- In general SFS is free for personal (private) use. However if you find SFS of use then in order to allow continued development of and enhancements to SFS, in particular the creation of more user-friendly versions of mksfs and mountsfs, of versions for other systems, of a low-cost plug-in card containing whole-disk encryption firmware, and the replacement of the drive I fried testing SFS, a donation of $25 would be appreciated. Alternatively, the donation can be used to cover the legal costs of those people involved in the current US government investigation of the PGP encryption program. Use of SFS in a commercial, government, or institutional environment or for business purposes is allowed for free for 30 days to allow it to be evaluated. After this period it should be registered for further use. The registration fee covers use of SFS on any one machine at any one time (so you could, for example, use SFS on a machine at work and keep a copy on your notebook PC for use while travelling). If you decide to send a donation or registration, please specify whether you'd like it to be used for further SFS development work or if it is to go into the PGP legal fund. Cheques or money orders can be sent to: Peter Gutmann 24 Durness Pl. Orewa Auckland New Zealand I can also be contacted through email at (among others) the following addresses: pgut1@cs.aukuni.ac.nz p.gutmann@cs.auckland.ac.nz peterg@kcbbs.gen.nz with the first address being the preferred one. Finally, the fastest way to contact me is by phone between about 10am and 1am at the following number (remembering that NZ local time is GMT+13, so we're usually about 18-20 hours ahead of the US and about 12 hours ahead of Europe): +64 9 426-5097 Testimony from one of our satisfied customers: "I hear this crash and I find a rock, wrapped in paper, next to my living room window. I open up the note and it says `You want it in writing? You got it. Next time, use a *real* encryption program. SFS. We know where you live'". So why aren't *you* using SFS? Here's what reviewers have been saying about SFS: "Version 1.0 has several of the advanced features recommended in version 0.9, but not all of the ones I'd like to see in version 1.1. So, it's pretty good except when it's not. Three stars. You probably won't use half the features anyway. I'm a little ticked off that it clashes with my most exotic memory-resident programs, but otherwise the software runs just fine on my Turbo Rambuster 586. It will probably run like molasses on your 386SX. It's great value at $25, and I recommend you register it, although that's easy for me to say because reviewers get freebies". Credits ------- Thanks to the readers of comp.os.msdos.programmer and comp.os.linux.development and in particular Jouni Kosonen, for their valuable advice with low-level DOS disk handling and organization, and the users of the Enigma BBS, in particular Arne Rohde, for helping test-run several early versions of the low-level disk handling code on various drive configurations and for providing useful advice on the vagaries of the PC's disk handling. Thanks also to Steven Altchuler for performing all sorts of dangerous tests on SFS volumes, and to Vadim Vlasov for help with various thorny problems with low-level disk and device driver programming. Matthias Bruestle (the greatest chemist of all time and space) provided valuable feedback on assorted problems in mksfs and mountsfs, and risked his disk drives testing the SFS driver and other SFS software. At the behest of the author he also risked imprisonment for Datenvergewaltigung by letting mksfs near his Linux partition. Colin Plumb made noises about various problems with CFB-mode encryption, corrected me when I tried to explain the need for encrypted IV's in email at 3am, and provided much useful feedback on SFS's operation in general, including the very elegant solution to the CFB-mode encryption problem and help with the disk overwriting method. Vesselin Bontchev sent in long lists of suggested improvements to SFS, and provided an ongoing commentary on features and ideas for the software (it seems half the functionality provided by SFS is due to his suggestions). Ralf Brown's interrupt list provided help with the haze of obscure interrupts used by mksfs in its quest for random information. The Beerdigungsinstitut Utzmann (erstes Erlanger Beerdigungsunternehmen) helped clean up the casualties from the SFS beta-testing. Finally, Tony, Geezer, Bill, Ozzy, Ron, and Grandos helped me stay awake during many long nights of debugging low-level disk access code and encryption routines. Various other people have at various times offered help and suggestions on getting SFS going. My thanks go to them also. Warranty -------- 1. Customer Obligations 1.1. Customer assumes full responsibility that this program meets the specifications, capacity, capabilities, and other requirements of said customer, and agrees not to bother the author if the program does not perform as expected, or performs other than expected, or does not perform at all. 1.2. Customer assumes full responsibility for any deaths or injuries that may result from the normal or abnormal operation of this program. In the event of casualties exceeding 1000 persons or property damage in excess of $10 million, customer agrees that he or she has stolen the program and we didn't even know he or she had it. 1.3. Customer agrees not to say bad things about the program or the author to anyone claiming to be from "60 Minutes". 2. Very Limited Warranty and Conditions of Sale 2.1. For a period of 90 minutes, commencing from the time you first thought about getting this program, we warrant that this program may or may not be free of any manufacturing defects. It will be replaced during the warranty period upon payment of an amount equal to the original purchase price plus $10.00 for handling. This warranty is void if the program has been examined or run by the user, or if the manual has been read. 2.2. This program is sold on an AS WAS basis. The author makes no warranty that it is, in fact, what we say it is in our propaganda, or that it will perform any useful function. We have no obligation whatsoever other than to provide you with this fine disclaimer. 2.3. Some countries do not allow limitations as to how long an implied warranty lasts, so we refuse to imply anything. 2.4. There is an extremely small but nonzero chance that, through a process known as "tunnelling", this program may spontaneously disappear from its present location and reappear at any random place in the universe, including your neighbours computer system. The author will not be responsible for any damages or inconvenience that may result. 3. Limitation of Liability 3.1. We have no liability or responsibility to the customer, the customers agents, our creditors, your creditors, or anyone else.